你覺得多久 Release 一次，才是合理的呢？ 每一週，每一天，還是...隨時?
在開始聊 Release 週期之前，想先來稍微聊一下 Release 對於公司的意義。在程式碼 Release 之後，其實才代表著真正的有東西交付到使用者手上，不管是修復一個 bug，一個小小的新功能，或是一個大家引頸期盼已久的殺手級功能，其實都代表著一個很重要的意義: 這個程式碼開始產生價值，並且能開始得到使用者的回饋。
由於這一點，在敏捷開發流程之中，盡快的交付，其實是一個對於持續改善來說非常重要的事情，只有透過盡快交付，你才能夠盡快的讓你開發的東西產生價值，並且開始知道這個功能能不能夠被使用者買單，如果只是一味的追求完美，花費長時間開發，這也其實代表著你在對使用者的需求做一個豪賭，賭你所做的正好是使用者想要的，不然的話，就代表著這一段長時間的開發就被浪費掉了，相反的，如果你能夠盡快的交付給使用者，就算這一個產出是相對失敗，對於公司帶來的損失也不會太大，畢竟開發的週期較為短暫。
如果從價值角度來看，如果我們假設走兩種不同的路線，第一種方法採用傳統的瀑布式開發，預計花費一年的時間改善系統，一年後系統上線預計可以讓營業額成長 50%，另外一種也是同樣的開發方式，但把 Release 週期改成每週一次，所以每週的功能開發可以讓營業額成長 50% / 52 (週) = 0.96%。然後我們試算一下經過兩年之後的營業額總額，可以發現採用每週 Release 的開發方式在兩年後可以讓營業額多 35%。
當然這些的前提是從一切都運行非常完美的角度來做計算，如果今天剛好遇到市場的重大變動，你會發現每週 Release 的可以快速根據市場反應來調整開發方向，但如果是每年 Release 的則會因為系統還沒上線，無法很明確的知道市場的變化，只能透過猜測來調整，甚至可能會因此而延宕時程，最糟的情況是會發現經過一年時間開發之後，所上線的系統功能已經不符合當下市場的需求了。
所以從上面的簡單計算之中，你就可以發覺每週 Release 和每年 Relase 的差異，但如果今天你能夠有良好的技術基礎，讓你能夠做每天 Release 甚至是 每天 Release 數次，那你可以想像在營業額的最後差距會有多大嗎? 如果今天有一個機會讓你重新選擇，你會選擇哪一種 Release 週期呢?
這篇分享讓大家知道，工程師也是可以貢獻業績的，在不異動所有已配置資源的情況下，只要縮短你的 Release 週期就可以囉！下一篇再來跟大家聊聊，該怎麼做才能夠縮短 Release 週期，提高交付價值的頻率。(本篇心得基於個人經驗作計算基礎，並且沒有驗算!)
Search